ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本
https://gyazo.com/130262cda7d32c337f81f85c3d193c9a
https://amzn.to/2wTpjOJ
#DDD(Domain-Driven_Design)
とても分かりやすい本
DDDについては全然知らなかったので勉強になった
DDDが提唱されたのは2003年頃
ドメインとは
知識
よくビジネスルールと呼ばれるもの
ゲーム開発の文脈では、作っているゲームに関する知識
ダメージシステム
報酬システム
ローグライクなシステム
入力と出力
ハードウェア
ビルドシステム
テスト
デバッグ方法
などなど
値オブジェクト
プリミティブ型よりもドメインにあった値オブジェクトを作る
int の数値よりも、Money型などを作る
不変
交換が可能
等価性によって比較
エンティティ
値オブジェクトと対をなす存在
ライフサイクルがある
Userなどを表す
可変
同じ属性であっても区別
同姓同名であっても、違う人間として扱うように
同一性をもつ
無口なコードにしておくよりも、饒舌なコードにしておく
ドメインサービス
ソフトウェア開発における「サービス」はクライアントのためになにかを行うオブジェクト
ドメインサービスは、"ドメインのための"サービス
値オブジェクトやエンティティのようなドメインオブジェクトに書くと不自然になる処理をドメインサービスで提供する
同姓同名のチェック
ドメインサービスに何でも処理を追加しすぎると、ドメインモデル貧血症になる
可能な限りドメインサービスは避ける
リポジトリ
ドメインオブジェクトの永続化や再構築を行うのが責務
アプリケーションサービス
"アプリケーションのための"サービス
ユースケースを実現する
例えば、「ユーザを登録する」や「ユーザ情報を変更する」などのユースケース
ユーザの操作のインターフェースとかになりそう
サービスは状態を持たないこと
依存関係のコントロール
依存性逆転の原則
上位レベルのモジュールは下位レベルのモジュールに依存してはならない、どちらのモジュールも抽象に依存すべきである。
抽象は、実装の詳細に依存してはならない。実装の詳細が抽象に依存すべきである。
Service Locatorパターン
IoC Containerパターン
ドメインモデル貧血症
Singletonをstaticのように使っていたら、素直にstaticで考える
ユーザーインターフェースを交換可能にする
ゲームだと、View無しモードで高速シミュレーションできるようにした。そういうケースのためにユーザーインターフェースを交換可能にする
ファクトリ
複雑な生成処理をカプセル化する
Factory Methodパターン
ユニットオブワークパターン
利口なUIアンチパターン
アーキテクチャ
レイヤードアーキテクチャ
ヘキサゴナルアーキテクチャ
クリーンアーキテクチャ
軽量DDDを避ける
境界づけられたコンテキスト
ドメインの世界と、一般的なシステムの世界とでコンテキストが違う。それの境界を明確にする
ゲームの中のUserと、一般的なデータベース管理におけるUserはコンテキストにおいて異なる意味になる
コンテキストマップを作り、対応づける
ボトムアップドメイン駆動設計